Automated Configuration of Medical Practice Management Systems

ABSTRACT

A user (e.g., medical office manager, medical office insurance administrator, doctor) utilizes a medical practice configuration interface (e.g., web page) to input information about the user&#39;s medical practice (e.g., address, insurance plans, doctors, hospitals that the doctors utilize). Based on this information and/or rules associated with the insurance plans accepted at the user&#39;s medical practice, additional information is requested from the user about the user&#39;s medical practice (e.g., information needed for an insurance plan, information needed for a hospital). The user inputs the requested additional information utilizing the medical practice configuration interface. Configuration information for the user&#39;s medical practice is generated based on the information and/or the additional information inputted by the user. A user interface (e.g., web pages interfacing with the medical practice management server) and/or rules for the medical practice can be generated based on the configuration information.

CROSS REFERENCE TO RELATED APPLICATIONS

This application is a continuation of U.S. patent application Ser. No.11/779,926 filed on Jul. 19, 2007, entitled “Automated Configuration ofMedical Practice Management Systems,” which claims the benefit of U.S.Provisional Patent Application No. 60/832,073, entitled “AutomatedInstallation and Configuration of Medical Practice Management Systems,”filed on Jul. 20, 2006, the disclosure of which is hereby incorporatedby reference.

TECHNICAL FIELD

The present invention relates generally to methods and systems,including computer program products, for automated configuration ofmedical practice management systems.

BACKGROUND

Before the advent of networked systems and computers, medical patientworkflow and billing was a manual process. Doctors, nurses, andreceptionists used paper-based records to keep track of which tests apatient had undergone, what the patient's insurance would and would notcover, and how claims for healthcare items and/or services would besettled. As computers became more widely utilized, many medicalpractitioners used computers for electronic record keeping and billingstatement generation.

With many medical practices, the number of patients that the practiceserves fluctuates from day to day or season to season. As a result, thenumber and/or complexity of transactions that a medical practicemanagement system processes for a given time period also fluctuates.These transactions, however, are important to the proper functioning ofa medical practice management system. Examples of transactions includepatient eligibility for a payment with respect to healthcare itemsand/or services, referral verification and approval, and claimsprocessing transactions. When interacting with third-party payors suchas insurance companies, it is often difficult to determine if thepayors' processing system can handle a given volume of data that needsto be processed for the medical practice management system to function.

SUMMARY OF THE INVENTION

One approach to automated computerized configuration of medical practicemanagement systems is a method. The method includes receiving firstinformation associated with a medical practice. One or more requests forsecond information are generated based on the first information and/orone or more insurance rules that apply to one or more payor servers,which are associated with the medical practice based on the firstinformation. Second information, which comprises information forsubmission of medical claims to the one or more payor servers, isreceived based on the one or more requests for second information.Configuration information for the medical practice management system isgenerated based on the first information and/or the second information.

Another approach to automated computerized configuration of medicalpractice management systems is a computer program product. The computerprogram product is tangibly embodied in an information carrier. Thecomputer program product includes instructions being operable to cause adata processing apparatus to receive first information associated with amedical practice. One or more requests for second information aregenerated based on the first information and/or one or more insurancerules that apply to one or more payor servers, which are associated withthe medical practice based on the first information. Second information,which comprises information for submission of medical claims to the oneor more payor servers, is received based on the one or more requests forsecond information. Configuration information for the medical practicemanagement system is generated based on the first information and/or thesecond information.

Another approach to automated computerized configuration of medicalpractice management systems is a system. The system includes a medicalpractice module and a server configuration module. The medical practicemodule is configured to receive first information associated with amedical practice. The medical practice module is further configured toreceive second information, which comprises information for submissionof medical claims to one or more payor servers, based on one or morerequests. The server configuration module is configured to generate theone or more requests for the second information based on the firstinformation and/or one or more insurance rules that apply to the one ormore payor servers, which are associated with the medical practice basedon the first information. The server configuration module is furtherconfigured to generate configuration information for the medicalpractice management system based on the first information and the secondinformation.

Another approach to automated computerized configuration of medicalpractice management systems is a system. The system includes a means forreceiving first information associated with a medical practice. Thesystem further includes a means for receiving second information, whichcomprises information for submission of medical claims to one or morepayor servers, based on one or more requests. The system furtherincludes a means for generating the one or more requests for the secondinformation based on the first information and/or one or more insurancerules that apply to the one or more payor servers, which are associatedwith the medical practice based on the first information. The systemfurther includes a means for generating configuration information forthe medical practice management system based on the first informationand the second information.

In other examples, any of the approaches above can include one or moreof the following features. The configuration information comprisesinformation utilized to select third information for submission to apayor server and/or information utilized to format the selected thirdinformation for submission to the payor server. The configurationinformation is merged with stored configuration information for themedical practice. The stored configuration information for the medicalpractice is replaced with the configuration information.

In some examples, whether to request additional information isdetermined based on the first information, the second information,and/or the one or more insurance rules that apply to the one or morepayor servers. One or more requests for additional information isgenerated based on the first information, the second information, and/orthe one or more insurance rules that apply to the one or more payorservers. Additional information, which comprises information forsubmission of medical claims to the one or more payor servers, isreceived based on the one or more requests for additional information.Configuration information for the medical practice management system isgenerated based on the first information, the second information, and/orthe additional information.

In other examples, the first information and the second information arebeing received from a user. A user interface is dynamically updatedbased on the first information and/or the second information.

In some examples, the first information includes medical groupinformation, tax information, provider information, legal information,department information, patient information, medical office information,hospital information, place of service information, signatureinformation, user information, and/or user permission information. Thesecond information includes payor information and/or informationassociated with an insurance rule.

In other examples, the first information is different from the secondinformation. The first information, the second information, and/or theconfiguration information is stored in a medical practice informationdatabase. One or more user interfaces for one or more users of themedical practice are generated based on the configuration information.The one or more users are healthcare professionals associated with themedical practice.

In some examples, one or more rules for the medical practice managementsystem are generated based on the configuration information. The firstinformation and/or second information are checked to determine if one ormore errors are associated with the first information and/or secondinformation. The one or more errors includes incorrect informationand/or missing information.

In other examples, one or more requests are generated for correctinformation. Correct information is received based on the one or morerequests for correct information. One or more rules associated with oneor more payor servers are utilized to check the first information and/orthe second information.

In some examples, the configuration information includes medical claimprocessing information associated with the medical practice, medicalclaim processing information associated with one or more payor servers,and/or medical claim information utilized to generate medical claims forsubmission to one or more payor server.

In other examples, a medical practice information database is configuredto store the first information, the second information, and/or theconfiguration information. The server configuration module is furtherconfigured to check the first information and/or second information todetermine if one or more errors are associated with the firstinformation and/or second information.

In some examples, the server configuration module is configured togenerate one or more requests for correct information and receivecorrect information based on the one or more requests for correctinformation.

Any of the approaches and examples above can provide one or more of thefollowing advantages. An advantage is that a medical practice canquickly and efficiently configure the medical practice management systemfor the individualized needs of the medical practice. Another advantageis that the cost of configuring and setting up medical practicemanagement systems for medical practices is significantly reducedthrough the use of the automated configuration. An additional advantageis that the medical practice management system can be quickly andefficiently changed based on changes to the medical practice. Anotheradvantage is that a user that is not experienced with the system canquickly and accurately customize the system for the user's medicalpractice which decreases the cost of switching to the system.

BRIEF DESCRIPTION OF FIGURES

The foregoing and other objects, features, and advantages of the presentinvention, as well as the invention itself, will be more fullyunderstood from the following description of various embodiments, whenread together with the accompanying drawings.

FIG. 1 is a functional block diagram of an exemplary system illustratinga medical practice management system.

FIG. 2 is a functional block diagram of an exemplary system illustratinga medical practice management system with multiple users.

FIG. 3 is a functional block diagram of an exemplary system illustratinga medical practice management server communicating with a medicalpractice network and a payor network.

FIGS. 4A-4Z are each an exemplary screenshot of a client interface in amedical practice module.

FIG. 5 is an exemplary flowchart depicting generating configurationinformation.

FIG. 6 is an exemplary flowchart depicting determining if additionalinformation is needed and determining if the information is correct.

DETAILED DESCRIPTION

Automating medical practice workflow and billing presents difficultiesin many aspects including installation of a system, processing theeligibility or other status information of patients, interacting withthe workflow, with other health care providers, and within theconstraints of payor requirements, as well as measuring the success of apractice once the workflow has been established.

In accordance with Applicant's technology, a user (e.g., medical officemanager, medical office insurance administrator, doctor) utilizes amedical practice configuration interface (e.g., web page) to inputinformation about the user's medical practice (e.g., address, insuranceplans, doctors, hospitals that the doctors utilize). Based on thisinformation and/or rules associated with the insurance plans accepted atthe user's medical practice, additional information is requested fromthe user about the user's medical practice (e.g., information needed foran insurance plan, information needed for a hospital). The user inputsthe requested additional information utilizing the medical practiceconfiguration interface. Configuration information for the user'smedical practice is generated based on the information and/or theadditional information inputted by the user. A user interface (e.g., webpages interfacing with the medical practice management server) and/orrules for the medical practice can be generated based on theconfiguration information.

For example, a medical office manager uses the web interface of themedical practice management system to input the medical practice'saddress, doctor information, hospital association information (in thisexample, the doctors have access to Big City Hospital), and insurancecompany information (in this example, medical practice accepts insuranceplan Omega). The medical practice management system checks the inputtedinformation using one or more rules associated with the hospital and theinsurance companies. Big City Hospital requires the Drug EnforcementAdministration (DEA) number for each of the doctors associated with thehospital. Insurance plan Omega requires information about whether themedical practice accepts nonpaying patients (e.g., charity patients).The web interface requests the DEA number for each doctor and whetherthe medical practice accepts nonpaying patients. The medical officemanager inputs the DEA number for each doctor and indicates that themedical practice will accept selected nonpaying patients (e.g., referredby a charitable organization). The medical practice management systemgenerates configuration information based on the information inputted bythe user about the medical practice. The configuration information isutilized by the medical practice management system to generate userinterfaces for the system and/or rules for the medical practice (e.g.,send the doctor's DEA number with every prescription order to the BigCity Hospital).

FIG. 1 is a functional block diagram of an exemplary system 100illustrating a medical practice management system. The exemplary medicalpractice management system 100 includes a user 110, a medical practicemodule 120, a network 130, and a medical practice management server 140.The medical practice module 120 includes a medical practiceconfiguration module 125. The medical practice management server 140includes a workflow processing module 150, a server configuration module155, a medical practice module 160, a medical practice informationdatabase 165, a payor module 170, and a payor information database 175.

The user 110 utilizes the medical practice module 120 to communicatethrough the network 130 to the medical practice management server 140.To setup the system 100 for use by the user's medical practice and/or tomodify the setup of the system 100 based on changes to the user'smedical practice, the user 110 communicates information about themedical practice to the server configuration module 155. The serverconfiguration module 155 generates requests for additional informationbased on the information from the user 110. The user 110 communicatesadditional information in response to the requests from the serverconfiguration module 155.

The server configuration module 155 generates configuration informationfor the medical practice based on part or all of the informationreceived from the user 110 about the medical practice. The serverconfiguration module 155 generates a user interface and zero or morerules for the medical practice based on the configuration information.

In some examples, the configuration information is communicated to themedical practice module 160 and/or stored in the medical practiceinformation database 165. The medical practice module 160 can utilize,for example, the configuration information to configure the medicalpractice management system 100 for the users at the medical practice.The configuration of the medical practice management system 100 for eachmedical practice includes, for example, the use of the names, addresses,doctor information, and/or other information associated with the medicalpractice of the user by the system 100 for interactions with the user.

In other examples, the configuration information includes informationfor submitting medical claims to payors from the medical practice. Forexample, insurance company Beta requires that all medical practices inMassachusetts submit the physical address of the office in which thepatient encounter occurred and the billing address for the medicalpractice. When the medical office manager 110 for medical practice Alphaconfigured the medical practice management system 100 for the medicalpractice, the server configuration module 155 requested the physicaladdress of each medical practice office in Massachusetts from themedical office manager 110. This information, the physical addresses ofeach medical practice office in Massachusetts, is part of theconfiguration information for medical practice Alpha and can be storedin the medical practice information database 165.

Although FIG. 1 illustrates only one user 110 from one medical practiceutilizing the medical practice management system 100, a plurality ofusers (e.g., 110) can utilize the medical practice management system 100to setup the system 100 for use by that user's medical practice. Forexample, Sue Allen, office manager of Feet are Us Docs, accesses theserver configuration module 155 through a medical practice module A (notshown) to setup the medical practice management system 100 for Feet areUs Docs medical practice. Paul Stevens, office manager of FeetSpecialists of Detroit, accesses the server configuration module 155through a medical practice module B (not shown) to setup the medicalpractice management system 100 for the Feet Specialist of Detroitmedical practice. The users (e.g., doctors, receptionists,administrators) of each medical practice can access the medical practicemanagement system 100 customized for their particular medical practice,Feet are Us Docs and Feet Specialist of Detroit.

In some examples, the user interface includes one or more web pages thatare utilized to display and/or receive information to/from the user 110.The user interface can be, for example, dynamically created based on theconfiguration information and/or the user permissions. The userinterface can be, for example, created based on the configurationinformation and/or user group permissions (e.g., office administratorgroup, insurance administrator group, receptionist group, doctor group).The user interface and/or information associated with the user interfacecan be, for example, stored in the medical practice information database165. In some examples, the user interface includes an application (e.g.,JAVA applet) executing on the user's computer.

In other examples, the zero or more rules for the medical practiceinclude rules for the processing of patient encounters, insuranceclaims, and/or any other type of patient interaction with the medicalpractice (e.g., billing). For example, the practice manager 110 atDentists for Everyone communicates information to the serverconfiguration module 155 that a copy of the primary insurance holder'sdriver's license is required for all insurance claims from Dentists forEveryone. When George Allen, the primary insurance holder, brings hisson, J. J. Allen, to Dentists for Everyone for a dental checkup, thereceptionist will ask George Allen for a copy of his driver's license.If the receptionist does not input (e.g., upload the image, verify thatthe copy was made and is in the patient file) the copy of George Allen'sdriver's license into the medical practice management system 100, thenthe rule requiring the copy of the license will not allow the checkoutof George Allen and his son to occur.

As another example, the practice manager 110 at Radiology Associates ofX-Ray communicates information to the server configuration module 155that only users in the insurance administrators group can submit medicalclaims to the payor servers. Based on this information, the serverconfiguration module 155 creates a rule for Radiology Associates ofX-Ray that does not allow the submission of medical claims (e.g.,insurance claim for payment) to payor servers (e.g., insurance companyservers) unless the user is a member of the insurance administratorgroup.

In some examples, the network 130 is a wide area network (WAN)connecting a plurality of medical practice offices to the medicalpractice management server 140 and/or a medical practice managementnetwork. The network 130 can be, for example, a public communicationnetwork (e.g., Internet) and/or a private communication network (e.g.,Intranet).

In other examples, the medical practice management server 140 is a webserver hosting a web application that the user 110 utilizes to submitand/or access information associated with the user's medical practice.The medical practice management server 140 can be, for example, aninformation interface that communicates information from a medicalpractice client application on a computing device 120 that the user 110utilizes to submit and/or access information associated with the user'smedical practice.

The patient and/or clinic workflow can be, for example, processed by theworkflow processing module 150. Although FIG. 1 illustrates workflowfunctionality via the workflow processing module 150, other examplesprovide workflow functionality via a message passing interface (notshown). The message passing interface can be utilized, for example, tocommunicate between the user 110 and the medical practice managementserver 140.

In some examples, the medical practice is the office of the medical careprovider (e.g., a doctor's office), a hospital, and/or any otherfacility for medical encounters. Although also referred to as aninsurance company, the payor organization can include, for example,health maintenance organizations (HMOs). Payor organizations include,for example, Century Health and Benefits, HMO Blue, Harvard PilgrimHealth Care, MassHealth, Medicare, Neighborhood Health Plan, TuftsAssociated Health Plan, and/or United Healthcare.

Before a medical practice can take advantage of the medical practicemanagement system 100, the system 100 is generally configured to workwith the medical practice. In some examples, the server configurationmodule 155 includes an automated practice management configuration tool.For example, a user 110 (e.g., a practice management consultant,employee of the medical practice) utilizing a user interface, typicallydisplayed on a Liquid Crystal Display (LCD) or Cathode Ray Tube (CRT),with a series of display screens that assist in configuring a medicalpractice management system 100. The user 110 is prompted for input(e.g., mouse clicks, keyboard presses) and the tool determines what thenext prompt for information is based on the input provided by the user110.

In some examples, information that is provided by the user 110 to thetool when setting up the medical practice includes, but is not limitedto, where the medical practice is located, offices or providersassociated with the medical practice that are or are not located at thelocation previously specified, departments, facilities, registrationwith insurance companies, registrations with government programs such asMedicaid, Medicare, and/or Clinical Laboratory Improvement Amendments(CLIA), a federal identification number associated with the practice,prior and existing patient appointments, prior medical servicesprovided, claim processing history, as well as contact informationand/or other information associated with the medical practice.

The screens present questions that are generally easy to answer foranyone familiar with the medical practice. Beneficially, there is littleto no need for expensive business analysts or system consultants toconfigure the system. Based on the answers provided by the user, thetool then configures the medical practice management system. In someexamples, configuring the medical practice management system involvescreating, updating, dropping, and/or modifying databases, tables, views,and/or stored procedures in a database, and rows and/or columns in adatabase table and the like.

The information received by the server configuration module 155 and/orthe medical practice module 120 includes medical group information, taxinformation (e.g., tax id), provider information, legal information,department information, patient information, medical office information,hospital information, place of service information, signatureinformation, user information, user permission information, payorinformation, information associated with an insurance rule, and/or anyother information associated with a medical practice.

FIG. 2 is a functional block diagram of an exemplary system 200illustrating a medical practice management system with multiple users210 a and 210 b. The exemplary medical practice management system 200includes the users 210 a and 210 b (e.g., healthcare professionalsassociated with the medical practice) who utilize medical practice Amodules A 220 a and B 220 b, respectively. The medical practice Amodules 220 a and 220 b include medical practice A interfaces A 222 aand B 222 b, respectively. The medical practice A modules A 220 a and B220 b communicate with the medical practice management server 240through a network 230.

The medical practice management server 240 includes a workflowprocessing module 250, a medical practice module 260, a medical practiceinformation database 265, a payor module 270, a payor informationdatabase 275, a master patient index module 280, and a patientinformation database 282. The workflow processing module 250 processesthe workflows of the patients and/or the office. The medical practicemodule 260 processes the configuration information stored in the medicalpractice information database 265, the user interface of each medicalpractice, and/or rules associated with each medical practice. The payormodule 280 processes insurance claims for submission to the payorservers based on one or more insurance rules stored in the payorinformation database 275. The master patient index module 280 processesrequests for patient information and retrieves patient information fromthe patient information database 282.

For example, the doctor 210 a and the receptionist 210 b at the GreatFeet Doctors of West Iowa medical practice access the medical practicemanager system 200 utilizing medical practice modules A 220 a and B 220b. The medical practice modules 220 a and 220 b are each of the users210 a and 210 respective desktop personal computers that have a webbrowser operating on them (in this example, medical practice interface A222 a and B 222 b which are web sites that include web pages configuredfor each user). The doctor 210 a can utilize her computer 220 a toaccess the web site 222 a that is configured for the doctor 210 a (e.g.,patient tests, patient test results). The receptionist 210 b can utilizeher computer 220 b to access the web site 222 b that is configured forthe receptionist 210 b (e.g., patient schedule, referral schedule).

Parts or all of the web site 222 a or 222 b can be, for example,dynamically created based on the configuration information and/or rulesfor the medical practice. For example, the basic design for the doctorweb site 222 a is pre-configured to include patient test and patienttest result sections based on information inputted during theconfiguration of the medical practice. Based on the information inputtedduring the configuration of the medical practice, the display ofreferrals for doctors is dependent on the doctor. When the doctor 210 aaccesses the web site 222 a, the rule for the doctor 210 a is to displaythe referral information for the patient, so the web page that thedoctor 210 a is viewing is dynamically updated to include the referralinformation.

FIG. 3 is a functional block diagram of an exemplary system 300illustrating a medical practice management server 340 communicating witha medical practice network 330 and a payor network 390. The medicalpractice management server 340 includes a workflow processing module350, a rules module 370, and an intelligent transactions relationship(ITR) module 380. The rules module 370 includes an insurance rulesmodule 372 and an insurance rules database 374.

The medical practice management server 340 includes a patientinformation database 362 and an insurance information database 352. Theworkflow processing module 350 stores part or all of the informationassociated with a patient in the patient information database 362. Thepatient information database 362 stores information associated withpatients of the medical practice. The information can include, forexample, the patient's address, phone number, zip code, height, weight,allergies, previous doctor(s), and/or other information associated withthe patient.

In some examples, the workflow processing module 350, the rules module370, and/or the ITR module 380 are software modules located within themedical practice management server 340. In other examples, the workflowprocessing module 350, the rules module 370, and/or the ITR module 380are externally located from the medical practice management server 340and communicate with the medical practice management server 340. Inother examples, the rules module 370 includes a patient rules module(not shown) that processes rules associated with patients, and/or othertypes of rule modules that process rules associated with healthcare.

In some examples, the workflow processing module 350 is a softwareapplication that controls and manages the features and functions of themedical practice management server 340. The workflow processing module350 and the medical practice module (not shown) communicate over themedical practice network 330. The medical practice module can transmit amedical care provider request containing information to the medicalpractice management server 340 using, for example, a common gatewayinterface (CGI) request. For example, when registering a new patient, amedical care provider operating the medical practice module enters therelevant patient information on a patient registration template that theworkflow processing module 350 delivered to the medical practice clientuser interface (not shown).

In other examples, the workflow processing engine 350 validates thestructure and composition of information entered by a medical careprovider at the medical practice client to ensure that the informationis correct (e.g., structure and/or composition). Examples of informationentered by a medical care provider at the medical practice clientinclude the patient's address, phone number, medical history, insuranceinformation, diagnosis and procedure codes, and/or other informationassociated with a healthcare patient.

In some examples, the workflow processing engine 350 communicates withthe rules module 370. The rules module 370 enables real-time applicationof “rules” stored in the rules database (not shown). A rule can be, forexample, coded logic that evaluates data and then performs an action.

The rules module 370 can access and update, for example, informationstored in the insurance rules database 374 using the insurance rulesmodule 372. Although FIG. 3 illustrates the rules module 370 external tothe workflow processing module 350, the rules module 370 can be, forexample, a software layer internal to the workflow processing module350. In some examples, the rules module 370 is implemented as anapplication program interface, a Component Object Model (COM) object, anEnterprise Java Bean, and/or any other type of database interfacemodule.

The insurance rules database 374 and/or the interface to the insurancerules database 374 can be written, for example, in a structured querylanguage. In some examples, the insurance rules module 372 uses aLightweight Directory Access Protocol (LDAP) to access information inthe insurance rules database 374. Additionally or alternatively, theinsurance rules database 374 can be external to the medical practicemanagement server 340 (e.g., distributed across three geographicallydispersed data centers) or can be internally situated in the medicalpractice management server 340.

The insurance rules database 374 includes insurance company rules thatdefine the appropriate format and content of clinical and claiminformation that the payor server (not shown) processes. In someexamples, the rules are subdivided into various classes. For example,the rules are divided into rules that have universal applicability toall claims for a specified payor, rules that apply only to one or morespecific insurance packages from among the variety of insurance packagesthat the payor offers to medical care providers, and/or rules that applyonly to specific medical care providers who provide care under one ormore specific insurance packages.

To ensure that the insurance rules database 374 contains current rules,the insurance rules database 374 can be, for example, frequentlyupdated. In some examples, individual payors transmit ruleupdates/creations to the medical practice management server 340 viatheir payor server. Rule specialists can, for example, review the rulestransmitted by the payor server and subsequently update the insurancerules database 374. In some examples, the rules specialist performs anyand all updates to the insurance rules database 374. In other examples,the updating of the insurance rules database 374 can be automated uponreceipt of a rule transmission from the payor server or the medicalpractice client.

In some examples, a medical care provider can submit information to themedical practice management server 340 for subsequent update of theinsurance rules database 374 based on the medical care provider'sexperience with one or more payors. In other examples, the insurancerules database 374 is updated with the server's historical analysis ofpreviously submitted claims, especially those that were denied, toidentify the reasons for denial. The historical analysis of previouslysubmitted claims can facilitate the development of new insurance rulesfor the insurance rules database 374.

In some examples, the medical practice management server 340 indexes thepatient information stored in the patient information database 362 bythe patient name. In other examples, the medical practice managementserver 340 indexes the patient information stored in the patientinformation database 362 with a patient identifier. The patientidentifier can be, for example, a random number, a predetermined integer(such as a patient counter), the patient's zip code, the patient's phonenumber, and/or any other type of identifier associated with a patient.The workflow processing module 350 can access the patient informationdatabase 362 using, for example, a master patient index module 360.

In other examples, the workflow processing module 350 stores informationassociated with an insurance company in the insurance informationdatabase 352. The information associated with an insurance companyincludes the insurance company's address, the amount of insurancecoverage for a particular patient, and/or other information associatedwith an insurance company. In some examples, the workflow processingmodule 350 can access the insurance information database 352 using aninsurance information database module (not shown).

In some examples, as the workflow processing module 350 receivesinformation from the medical practice client, the workflow processingmodule 350 determines on a real time basis whether all of the requiredinformation has been provided and/or whether the information is in thecorrect format. In the event that there is a deficiency and/or error inthe information, the workflow processing module 350 alerts the medicalcare provider (e.g., receptionist), or user, for additional informationand/or to correct the information. In other examples, the workflowprocessing module 350 corrects the defect and/or error.

For example, if the insurance rules module 372 contains a rule aboutmember identification formatting for a particular payor, the insurancerules module 372 determines the rule in the insurance rules database 374and communicates the information to the workflow processing module 350.The workflow processing module 350 communicates this information to themedical practice client when a medical care provider (e.g.,receptionist) is registering a patient. If the medical care provider(e.g., receptionist) errs, the medical practice management server 340alerts the medical care provider (e.g., with a warning message) tocorrect the error. This enables medical care providers to generateclaims with no errors (i.e., referred to as clean claims) for the mutualbenefit of the medical care provider and the payor. Additionally, themedical care providers can obtain the information associated with analert while the patient is physically present (e.g., while the patientis still at the hospital, during their encounter, before checking out).

The workflow processing module 350 can be, for example, in communicationwith the ITR module 380. The ITR module 380 executes transactions sentto and/or received from the payor server via the payor network 390.Thus, the majority of provider/payor transactions can be accomplishedelectronically, with little or no human intervention. Examples of thesetransactions include, without limitation, claim submittals, claimreceipt acknowledgements, claim status checks, patient eligibilitydeterminations, authorization and referral requests and grants, and/orremittance advice. For example, a predetermined number of days before ascheduled patient visit, the ITR module 380 automatically checks patienteligibility with the applicable payor identified during the patientregistration process. After a patient visit and the completion of theclaim template, the claim is submitted to the payor server via the ITRmodule 380.

In some examples, upon receipt of an insurance claim, the payortransmits a confirmation back to the medical practice management server340. Later, on a schedule determined by the medical care provider (e.g.,weekly, monthly), the ITR module 380 checks the claim status andnotifies the medical practice client accordingly. After the ITR module380 analyzes the claim and generates remittance advice, the ITR module380 parses the electronic payment and allocates the payment among theindividual charge line items for the services provided. Once the medicalcare provider approves the allocations, the payments are posted to theprovider's accounts.

In other examples, insurance rules database 374, insurance informationdatabase 352, and/or patient information database 362 are encryptedwhich advantageously complies with applicable laws and/or regulations.The information stored and/or associated with the medical practicemanagement server 340 can be, for example, encrypted. The encryption ofdatabases and/or information can be, for example, advanced encryptionstandard (AES), data encryption standard (DES), and/or any other type ofencryption method and/or module. The encryption can be, for example,hardware based encryption and/or software based encryption.

In some examples, financial information is removed from the insurancerules database 374, insurance information database 352, patientinformation database 362, and/or any other information stored and/orassociated with the medical practice management server 340. Part or allof the financial information can be, for example, removed and/or hidden(e.g., remove all but the last four digits of the social securitynumbers). The financial information can be, for example, removed fromthe primary database where the information is being stored (e.g.,patient information database 362) and stored in a separate database. Forexample, the social security numbers are removed from all patientinformation stored in the patient information database 362 and placed inthe secure patient information database (not shown). The information inthe patient information database 362 and the secure patient informationdatabase can be associated with each, for example, by utilizing anassigned patient ID. The information in the secure patient informationdatabase can be secured, for example, utilizing a password, personalidentification number, biometrics, and/or any other security mechanism.The financial information can include, for example, social securitynumbers, credit card numbers, bank account numbers, and/or any otherinformation associated with finances.

Although FIG. 3 illustrates the modules insurance rules module 372,workflow processing module 350, master patient index module 360, andintelligent transaction relationship module 380 as separate modules, themodules 372, 350, 360, and 380 can be combined, for example, into onemodule or any number of modules. Similarly, the databases, insurancerules database 374, insurance information database 352, and patientinformation database 362 can be combined, for example, into one databaseand/or can be external or internal to the medical practice managementserver 340.

FIGS. 4A-4Z depict one implementation of the automated configurationtool. FIG. 4A depicts a user interface to the tool that a user utilizesto configure the medical practice management system for the medicalpractice. Areas that are configurable via the tool include, but are notlimited to, practice, payors, patients, operations, financials,training, and/or any other type of information associated with a medicalpractice. Within each area, there are typically sections that havecorresponding “tabs” labeled with the section name. For example, asdepicted, the area selected is “practice” and the section selected is“departments.” Typically, if a user clicks on the section name link,they will go to a configuration page, e.g., a “Setting up . . . ” page,for that section. Beneficially, though medical practice is discussed andillustrated, similar features are provided to configure payors,patients, operations, financials, training, and/or any otherconfiguration for a medical practice.

FIG. 4B depicts a table of contents for a practice chapter. The overviewillustrates the status of particular sections, the sections indicated byHTML hyperlinks. The hyperlinks allow a user to go directly toparticular sections to configure information for that section ratherthan go through the steps of configuring the system for all aspects ofthe medical practice each time the tool is used. As depicted in FIG. 4B,the tool has been used to configure multiple aspects of the medicalpractice (e.g., Medical Groups, Departments, and Providers). A statuscan be provided, for example, after a particular aspect (in thisexample, check mark, yield, and issue). When a user completes (orpartially completes) any page in a section, the table of contents'summary sections and chapter review page is updated with a green (inthis example, check mark), yellow (in this example, yield) or red (inthis example, issue) audit symbol to show that a section has been workedon. If one or more errors or warnings exist in a section, a red errorsymbol is displayed next to the section summary row.

For example, in FIG. 4B, a check mark appears before “Summary of MedicalGroup Information.” The check mark indicates that the Medical Groupsection has been completed successfully with no validation errors. Asdepicted, a yield sign with an exclamation point appears next to“Summary of Department Information.” The yield sign with an exclamationpoint typically indicates that the Department section was completed buthas inconsistencies and/or errors. The errors can be, for example,incomplete information, incorrect information, and/or any other error.The tool determines if a section has incomplete and/or incorrectinformation by using business logic associated with configuring thepractice to determine that the configuration cannot be completed withthe existing provided information. A red circle with an “X” inside thecircle appears next to the “Summary of Provider Information” hyperlinkindicates that information necessary to configure the system is missingor has not been provided. A clickable button is provided to advance tothe next screen.

In some examples, business logic is executed that checks the validity ofinformation when each page is navigated away from (e.g., when a “next”button is pressed, the user wishes to exit the system). In otherexamples, business logic is executed which checks the validity of theinformation provided to the tool when all aspects of the section havebeen completed (e.g., on a section summary page).

In some examples, the first time a user attempts to configure the systemfor the medical practice, the button displays the text “Start PracticeChapter.” Upon a second or subsequent visit, the button displays thetext “Resume Practice Chapter.” In some implementations, clicking the“Resume Practice Chapter” button navigates the user to the lastconfiguration display the user visited. In some versions, the user isreturned to the first configuration display that has errors and/orwarnings.

FIG. 4C depicts an introductory screen to the configuration tool thatexplains a medical group. The screen displayed to the user provides anexample explaining the difference between one medical group and twomedical groups (e.g., depending on how insurance companies issue paymentto the doctors associated with the medical practice). Additionally,information associated with a claim form (in this example, CMS-1500) isexplained. Beneficially, relating the information being explained to anexisting medical form advantageously increases the user's comfort if theuser is familiar with a paper-based claim reconciliation workflow. Auser clicks a mouse pointer on the “continue” button, which instructsthe tool that the user is ready to view the next screen. The toolprocesses the click on the continue button and dynamically generates thenext screen for the user, in this implementation, a page for entering aFederal ID number.

FIG. 4D depicts a page for entering a Federal ID Number. On the page isa “Tell me more” hyperlink. In any page or display, a user can bepresented, for example, with a “Tell me more” link that providesadditional useful information to the user. In the example depicted, the“Tell me more” link opens a new window with appropriate text. A FederalID is typically an alphanumeric sequence and generally limited to twenty(20) characters. If the user does not provide a Federal ID number andclicks the Back button, the user is returned to setting up a medicalgroup page. If the user clicks the Continue button, the user isnavigated to the “Enter Practice Name” page.

In some examples, if the user types anything in the Federal ID numberfield, the user is also required to choose a radio button. If user typesin Federal ID number field and clicks “Continue” or “Back” withoutchoosing a radio button, typically a prompt appears informing the userto “Please indicate whether this number is a Social Security Number or aTax ID.” If user chooses SSN, the user is navigated to an “EnterProvider Name” page. If user chooses Tax ID, the user is navigated to an“Enter Legal Practice Name” page.

In other examples, when a user navigates away from a page, validation isperformed on the information provided by the user to the tool. Examplesof validation rules that may apply to Federal ID number include, but arenot limited to: the Federal ID field must be populated and a radiobutton must be chosen identifying the entry as a Tax ID or a SSN, aSocial Security number must be 9 digits and numeric, only charactersallowed are two dashes, one after 3 digits, one after 5 digits, and/or aTax ID must be numeric and contain no characters.

FIG. 4E depicts a page to enter a provider name. In someimplementations, some pages provide the ability to add multiple items(e.g., multiple medical providers). To add multiple entries, the user istypically provided with a prompt ( e.g., “do you have another X,” whereX is the item being entered). On these pages, there are typically Yes/Nobuttons provided so the user can either add another element or not.

On the provider name page, typically the social security number providedto the previous screen is displayed on the provider name page. Exemplaryinformation that the user provides with respect to a provider is first,middle, and last name, any suffixes that apply (e.g., Jr.), degrees theprovider holds, the provider's medical group membership and/or theirspecialty. Additionally, there is a taxonomy input that can be used toprovide further detail with regard to the provider's specialty. In someexamples, the drop-down menu for degree includes only “M.D.” or “D.O.”In other examples, medical group name is created using data entered onthe provider's name page in the following format: First name, Middle,Last Name, Suffix, Degree. The billed name can be created, for example,using format: First initial, Middle Initial, Last Name (no spaces),Degree (no punctuation).

In some examples, the back button takes the user to the “Enter FederalID” page where the user is presented with the number they entered andthe radio button they previously chose. The user can edit the Federal IDnumber text field and choose a different radio button. If the user doesthis, the tool behaves the same as it did after the first entry ofinformation (e.g., navigate the user to the “Enter Provider's Name”page). If the user already provided information on “Enter Provider Name”page, the page typically does not save that data if user clicked the“back” button to navigate away from the “Enter provider's name” page.When the user returns to the “Enter provider's name” page by clickingcontinue on Federal ID page or by clicking the link on the Table ofContents page, the “Enter provider's name” page is presented and amessage stating “you've entered SSN <insert SSN number> . . . ” so theuser knows which medical group they were in the process of adding.

If user clicks the Yes button, the user is navigated to the “EnterFederal ID” page which typically appears empty. If user clicks No, theuser is navigated to the “Summary of Medical Group Information” page. Aswith the Federal ID number page, validation is performed against thedata entered onto the page. Examples of validation for the provider namepage include, but are not limited to, the First name and Last namefields must be populated with letters (periods, single quotes and dashesallowed), and the Degree must have a value (e.g., a selection in thedrop down list was chosen).

FIG. 4F depicts a page to enter the Legal Practice Name. The Federal IDnumber and/or Tax ID can be, for example, displayed from the “EnterFederal ID Number” page. A text field for entering the medical practicename can be, for example, displayed. The back button navigates the userback to the “Enter Federal ID” page which would show the Federal IDnumber entered and radio button chosen. The Yes button navigates theuser back to “Enter Federal ID” page with a blank number field and noradio button chosen. The No button navigates the user to the medicalgroup summary page. Validation for the legal practice name pageincludes, but is not limited to: practice name must be populated withletters (periods, commas, single quotes, and dashes allowed).

FIG. 4G depicts a summary page for the medical group informationsection. A summary page for a medical group information section displaysone medical group per row. In some examples, the summary page providesupdate, delete, and/or add functionality for rows displayed on thesummary page. Clicking update returns the user to the page where theinformation was first entered. When using “update,” however, for pagesthat include a “do you have another x?” option, the user is presentedwith a continue button instead rather than the opportunity to add moreelements. Once update has been done, pressing the continue buttonnavigates the user to the summary page.

In some examples, if the user chooses the delete link, a pop up boxappears asking, “Are you sure you want to delete this <insert medicalgroup, department or provider, depending on section>?” with OK andCancel, “OK” being the default option if user hits “Enter.” If userclicks OK, the row is deleted from the page. If any data was written toa database during configuration, the information associated with the rowinside the database is also deleted. If user clicks cancel, the alertbox disappears and user remains on section summary page with no changes.

In other examples, if user wants to add a medical group, department,and/or provider from respective section summary pages, he can click onthe link “add <medical group, department, or provider>.” The link takesuser to first point of the respective medical group, department, orprovider entry pages. Summary pages do not typically contain a Backbutton, though in some versions the summary page does. The user isgenerally able to use the update link to view previously enteredinformation.

In some examples, on a summary page for a given section, when a userclicks the “Continue to next section” button, validation is performed onthe data provided in the current section, e.g., the medical groupsection, both on the individual data fields (like was performed on theindividual pages), and on the summary page data as a whole. Examples ofsummary page validation include, but are not limited to: the samemedical group name cannot exist in more than one row, the same providername cannot exist in more than one row; the same Federal ID number (SSNor TIN) cannot exist in more than one row, and the practice must have atleast one medical group. Depending on the success or failure of thevalidation logic, statuses are displayed on the summary page.

For example, if all validation rules are passed successfully (i.e., allthe data entered is valid data) no alerts are displayed on the summarypage. If, however, there was a validation failure for one of the rows,warning symbols are displayed next to the row in which data is missingor invalid. In some examples, text is displayed on the screen when theuser moves a mouse cursor over the error symbol. The text can read:“<insert error>. Click the update link to correct problems.” If theaudit failed because of errors between rows (e.g., two medical groupshave the same name) typically an error message is displayed below thesummary data (with error symbol to left of message). An example errormessage includes “You cannot have more than one <insert medical group,provider, or Federal ID number>with the same name. Please correct thiserror,” or alternatively, “Your practice must have at least one medicalgroup. Please enter a medical group.”

In some examples, a user is able to continue to the next section withoutfixing the errors, but the errors will appear again when the chaptervalidation is performed. In those examples, the user will not be able tocomplete the chapter without fixing the errors.

In addition to configuring medical group information, departmentinformation is configurable. FIG. 4H displays an introduction to thedepartment section, explaining that departments are typically associatedwith a location. Clicking the continue button navigates the user to the“Where do your providers see patients?” page.

FIG. 41 is an exemplary “Where do your providers see patients?” page.Three checkboxes are presented to the user (in this example, Office,Hospital and Other). In some examples, other checkboxes are presented tothe user (e.g., Out Patient Facility, Home). Depending on answersprovided by the user, the user is navigated to specific pages.

For example, if the user selects Office only, go to an Office name page,as illustrated by FIG. 4J, then an office address page (FIG. 4K). Ifuser clicks Yes to the “Do you have another office?” prompt on theoffice address page, the user is navigated back to the office name pageagain to enter the new office. If user selects No on the office addresspage, the user is navigated to the Summary page, as illustrated by FIG.4Q. If user selects Hospital only, the user is navigated to a hospitalname page, as illustrated by FIG. 4L, and then to a hospital addresspage, as illustrated by FIG. 4M. If user selects Yes to add anotherhospital on the hospital address page, the user is navigated back to thehospital name page. If user selects No, the user is navigated to thedepartment summary page, as illustrated by FIG. 4Q.

If the user selects Other only, the user is navigated to the “enteradditional place of service” page, as illustrated by FIG. 4N, and thento an “enter ‘place of service’ name” page, as illustrated by FIG. 40.The enter place of service name page typically indicates the first“place of service” type name chosen on for the “enter additional placeof service” page. After the “enter place of service name” page, the useris navigated to the enter place of service address page, as illustratedby FIG. 4P. If user selects Yes to enter another place of service type,on the “enter place of service address” page, the user is navigated backto the “enter additional places of service” page. Typically the userwill be navigated back with same place of service type name inserted infirst sentence and the name fields are blank. If user selects No and theuser chose more than one place of service type on the enter additionalplaces of service page, the user is navigated to next place of servicetype name inserted in first sentence and name fields are left blank. Ifuser selects No and he did not choose more than one place of servicetype on the “Where do your providers see patients” page, the user isnavigated to the summary page, as illustrated by FIG. 4Q. If the userselects a combination of the above, the user is navigated through thepages in order with office first and place of service last.

FIG. 40 depicts one implementation of the “Enter ‘Place of Service’(POS) name” page. As part of the display, the POS type chosen on the“Enter additional places of service” page is displayed. In someexamples, a link “Oops, I picked the wrong one” is included thatnavigates the user back to the “Enter additional places of service” pagewhere user can deselect the POS type. If the user deselects POS type andhas already entered data for each POS type selected, the continue buttonnavigates the user to the summary page. If user deselects POS type, buthas not entered data for each POS type selected, the continue buttonnavigates the user to the “Enter POS Name” page.

FIG. 4Q depicts a summary page for the departments section. In someexamples, each type of department has its own row, and the address,phone, and fax are repeated for each type. When the user clicks the “adddepartment” link, a dialog box is displayed (FIG. 4R) asking “Which typeof department would you like to add?” typically with radio buttonchoices of office, hospital, or other.

In other examples, FIG. 4R includes buttons for Cancel and OK, with OKbeing the default choice if the user hits Enter. Office choice navigatesthe user to the enter office name page, as illustrated by FIG. 4J.Hospital choice navigates the user to the enter hospital name page, asillustrated by FIG. 3L. Other navigates the user to the “enteradditional places of service” page, as illustrated by FIG. 3N. When theuser finishes entering the new department, the continue button returnsthe user to the department summary page where the user can choose the“add department” link again if they need to.

Departments, like medical groups, also utilize business logic(validation rules) to determine if the entered data is valid. In someexamples, department validation logic includes, for example: all namefields must be populated with letters (periods, commas, and dashesallowed), all address fields must be populated (free text field, norules), all city, state, zip, and phone fields must be populated, faxfields are optional. Additional rules include, for example, on the enterhospital name page, as illustrated by FIG. 4L, at least one hospitaltype box must be checked. Such logic is typically performed using stringcomparison functions and/or any other logic operation.

In addition to the individual fields, validation can be, for example,run against the department data as a whole. For example, office,hospital, and place of service names cannot be duplicated. If nohospital is provided by the user at all, a warning is displayed thatreads: “You indicated that your providers do not see patients in ahospital. If this is incorrect, make sure you use the add departmentlink to add a hospital.” If no office is provided, a warning isdisplayed that reads: “You indicated that your providers do not seepatients in an office. If this is incorrect, make sure you use the adddepartment link to add an office.” If the user indicated that they had acertain POS, yet didn't enter any data for it, a warning is displayedthat reads: “You indicated that you had the following place of servicetype: <insert type of POS>, but you have not entered any data about thisfacility. If you chose this place of service type by mistake, return tothe ‘Where do your providers see patients?’ page and deselect this POStype. Otherwise, please click ‘add another department;’ choose ‘Other;’and select the appropriate POS.” In other examples, a practice must haveat least one department for the practice entry to be valid. Results ofthe validation of the section are similar to those of the medical groupwith respect to error messages and rollover text (e.g., error messagesand/or rollover text) includes, for example:

-   -   Displaying an error symbol next to a row in which data is        missing or invalid, with rollover text reading:“<insert error>.        Click the update link to correct problems.”    -   Displaying an error symbol next to a row in which data is        missing or invalid, rollover text reading: “You entered a        hospital department, yet you did not choose a type of department        for this hospital. Please correct this error.”    -   Returning an error message below the summary data (with error        symbol to left of message) stating: “You cannot have more than        one department with the same name. Please correct this error.”    -   Returning an error message below the summary data (with error        symbol to left of message) stating: “Your practice must have at        least one department. Please enter a department.”

In some examples, there is a section to configure providers for themedical practice, depicted in FIG. 4S. Beneficially, if the user alreadyprovided the information for a provider as a medical group (e.g., asingle practitioner) the tool can re-use the original information and/orconfigure the medical practice to use the medical group information forthat provider without additional information. For example, in someversions, if a social security number was provided to the tool whenconfiguring the provider, the following text is displayed below lastparagraph (of FIG. 4S) “Remember, you already entered <b><Dr. LastName></b> during medical group setup. You <b> do not</b> need to enterhim as a provider because he has already been entered.” where <Dr. LastName> is substituted with “Dr.” and the last name of the person thatmatches the already provided social security number.

FIG. 4T depicts an exemplary “enter provider” page for enteringinformation about a provider. If a provider was already entered in themedical group section, the First Name through Degree fields arepre-populated with that provider's information. If the provider was notalready entered during the medical group section, the fields arepresented as blank fields. Once the user has completed the First name,Last name and Degree fields, clicking Yes will save the data and clearthe fields so the user can enter another provider. If the user is done,the user, upon clicking No, is navigated to the Signatures on File page,illustrated by FIG. 4U.

If the user has not completed those fields, clicking No navigates theuser to the summary page for providers, illustrated by FIG. 4V. Whenthat happens, a warning appears on the summary page for providers nextto the row due to missing fields. In some implementations, the degreedrop down includes the following options:, MD, Doctor of Osteopathy(DO), Nurse Practitioner (NP), Physician's Assistant (PA), MedicalAssistant (MA), Registered Nurse (RN), Licensed Practical Nurse (LPN),Resident, Locum Tenens, Certified Nurse Midwife (CNM), PerinatalCoordinator (PNC), Nutritionist (NUTR), Physical Therapist (OTR),Licensed Physical Therapist (LPT), Licensed Physical Therapy Assistant,Doctor of Podiatric Medicine, Doctor of Chiropractic, Certified ClinicalAudiologist, Certified First Assistant, Certified Surgical Technician,MS/RD, Clinical Psychologist (EDD), Clinical Psychologist (PHD), SocialWorker, Master Social Worker (MSW), Licensed Social Worker (LCSW),Licensed Professional Counselor (LPC), and/or Optometrist (OD).

In other examples, the medical group membership drop down menu includesall medical groups entered in medical group section. Generally, thespecialty drop down menu includes various specialties (e.g., internalmedicine, family practice). Beneficially, the tool can populate thespecialty dropdown and the taxonomy look-up with specialties andtaxonomical information stored in the databases of the medical practicemanagement server. If necessary, upon navigating to the provider summarypage, illustrated by FIG. 4V, the user can click “add provider link” toget back into provider workflow.

FIG. 4U is an exemplary “signatures on file” page: Typically thesignatures on file page displays all the providers who have been entered(First name, Middle initial, Last name, degree) with check boxes next tothe respective provider's names. The checkboxes should generally all bechecked for the page to pass the validation business logic.Advantageously, the “signatures on file” page ensures that a medicalpractice is complying with HIPAA regulations that every provider have asignature on file with the medical practice where they provide services.

FIG. 4V depicts one implementation of a summary of provider informationpage. Like the medical group and the department sections, the summary ofprovider information page executes validation business logic todetermine if the values provided in each field during configuration werevalid. In some examples, validation includes first name and last namefields must be populated with letters (periods, commas, single quotesand dashes allowed), all fields except middle name and suffix must havevalues to pass, and/or each provider should have signature on filechecked. Additionally, the section as a whole has validation businesslogic. For example, combinations of provider first name and last namecannot be duplicated and the practice must have at least one provider.

If the field values fail the validation, an error symbol is displayednext to the row in which data is missing or invalid. Rollover text ispresented that reads, “<insert error>. Click the update link to correctproblems.” If there is no signature on file for a provider, a warningsymbol next to appropriate row is displayed, with rollover text reading,“You indicated that you do not have a signature on file for thisprovider. If this is true, the medical practice management system willnot be able to submit claims on his or her behalf.” If multipleproviders have the same combination of first name and last name, anerror is displayed, stating “You cannot have more than one provider withthe same name. Please correct this error by updating the properentries.” If no provider is provided, an error message is displayedstating, “Your practice must have at least one provider. Please enter aprovider.”

FIG. 4W depicts one implementation of an “end of practice chapter” page.Beneficially the “end of practice chapter” page provides links to eachof the sections. If errors still exist within a section, a graphicappears next to the link for that section to alert the user that thereis still an error. Advantageously, the user may return to a givensection to add, update, delete, etc., data in that section, but the userdoes not have to go through the entire medical practice managementsystem set up again.

In some examples, different messages are displayed on the end ofpractice chapter page depending on if errors exist with the sections ornot. If no errors and no warnings in any of the sections, typically amessage such as, “if you would like to review your work beforeproceeding, use the links below.” If at least one error and no warningsthe message “the <insert section name> section contains errors. Clickthe <insert section name> link to return to Summary page and fixerrors,” is displayed.

If the user is done, the user clicks the “I'm done” button andvalidation business logic is performed on the entire practice chapter.If the values and sections pass the validation business logic, the useris navigated to the review of practice chapter page, illustrated by FIG.4X, and the user is done.

If, however, there are errors in some of the fields, the user isnavigated to a review of practice chapter page that displays an errormessage, illustrated by FIG. 4Y. When an error still exists, a link isprovided to section summary page that contains the errors. The usertypically must fix all errors before he can proceed. Once the last erroris fixed, success or warning message appear.

Lastly, if no errors exist, but the system has provided warnings, theuser is navigated to review of practice chapter page that displays thewarnings along with links to the appropriate sections, illustrated byFIG. 4Z. Warnings are the typically the same as section summarywarnings, but include some context. For example, warnings should beprefaced with, “In the Provider section, <insert warning>”. This reviewof practice chapter page allows a user to accept the warnings byproviding an OK button. If the user clicks on the OK button, the userhas acknowledged that they have seen the warnings and do not need to fixthe potential configuration issues. However, if user goes back to asection that has a warning and does something that should generate a newwarning, that new warning should appear next time user gets to theChapter review audit.

Beneficially, the information provided during the setup allows the toolto configure the medical practice management server to be utilized bythe practice. Similar features are provided for setting up payors (e.g.,providing payor addresses and claim submission information) patients,operations, financials, and/or training.

In some examples, rather than guiding the user through a series ofscreens for a particular question area, data upload capability isprovided. For example, in one version a user is presented with an inputto upload a provider database or spreadsheet (“upload data”). The uploaddata includes information associated with a medical services provider(e.g., a doctor's name, address, and billing identifier). The userprovides the upload data, and the interface is changed in response. Insome examples, the response is an acknowledgement that the upload datawas uploaded successfully. In other examples, the upload data isexamined and values are stored in a data repository (e.g., inserted intoa database table(s)) representing values in the upload data,relationships between values in the upload data, or both. For example,if Doctor Smith and Doctor Doe are providers associated with the medicalpractice, and both work at the same location, in one example, theaddress for each is stored in a data repository, as is the relationshipthat each is associated with that address. In some examples, the user isthen prompted to accept the relationship.

In some examples, during configuration, the tool stores the inputreceived from the user, preferably in a temporary database. In theseexamples, if a user exits the automated configuration, or returns to anearlier portion of the configuration, the system displays the previouslyreceived input when the user returns to a screen where the user hasalready provided input. For example, using the example above, after theuser has provided that the medical practice is not associated with amid-wife, assume the user exits the configuration program beforecompleting the configuration. When the user begins the automatedconfiguration tool again, the non-association with the midwife isretrieved and requires no further input from the user. The tool thenprovides the next set of screens (e.g., does the medical practiceprovide pre-natal education classes). This is beneficial in that if auser is forced to exit (e.g., for computer system maintenance) the usertypically does not have to re-enter information, thus saving time spentconfiguring the system. In some examples where temporary tables areused, data is copied into non-temporary database tables at periodic timeintervals, after the completion of the automated configuration tool, orboth.

In some examples, as the user provides input, the tool configures themedical practice management system. Continuing the previous example,because the medical practice is not associated with a mid-wife, the tooldoes not create data structures (e.g., database tables, columns) forentering mid-wife information. But because the medical practice providespre-natal education classes, data structures associated with thatservice are created.

Additionally or alternatively, based on the configuration informationprovided, in some examples, workflow rules are created for use by theworkflow processing module. For example, as a patient in checking orchecking out, the medical practice management system determines thereason for the patient's visit. Because the patient's visit to themedical practice is associated with an early pregnancy check up, themedical practice management system, and because the medical practiceoffers pre-natal classes, the medical practice management server promptsthe user of the medical practice module to inform the patient about thepre-natal classes.

FIG. 5 is an exemplary flowchart 500 depicting generating configurationinformation utilizing the medical practice management system 100 ofFIG. 1. The server configuration module 155 receives (510) firstinformation that is communicated by the user 110 through the medicalpractice module 120. The server configuration module 155 generates (520)requests for additional information from the user 110. The serverconfiguration module 155 receives (530) second information that iscommunicated by the user 110 through the medical practice module 120 inresponse to the requests for additional information. The serverconfiguration module 155 generates (540) configuration information forthe medical practice to utilize the medical practice management system100. The server configuration module 155 generates (550 a and 550 b) auser interface to the medical practice management system 100 and rulesfor medical practice management system 100, respectively, based on theconfiguration information.

For example, a medical office manager 110 utilizes the medical practiceconfiguration module 125 (e.g., configuration user interface) on themedical practice module 120 to input the medical office's address (inthis example, 123 Main Street West City, N.J.), doctor information(e.g., name of doctors in the practice, degree of each doctor), and theinsurance company identification (i.e., the insurance companies andplans that are accepted by the medical office). The server configurationmodule 155 receives (510) the information about the medical practice.The server configuration module 155 generates (520) requests foradditional information based on the information and on rules associatedwith the identified insurance companies and plans that are accepted bythe medical office. The medical office had indicated that it accepts thepremium high insurance plan from insurance company Medical Omega. Basedon a rule stored in the payor information database 175 from the premiumhigh insurance plan at Medical Omega which indicates that the insurancecompany requires a specialist associated with the specific type ofmedical encounter approve the medical encounter if the cost exceeds$1,000, the server configuration module 155 generates (520) a request tofind out the specialty of each doctor in the medical practice.

The medical office manager 110 responds to the request with additionalinformation and the server configuration module 155 receives (530) theadditional information (in this example, the specialty of each doctor inthe medical practice). The server configuration module 144 generates(540) configuration information based on the information received fromthe medical practice. The configuration information includes thespecialty of each doctor in the medical practice so that the informationcan be submitted with insurance claims for the premium high insuranceplan from insurance company Medical Omega.

The server configuration module 155 generates (550 a) a user interface(e.g., a plurality of web pages for use by the medical practice) for useby the medical practice. The user interface includes fields thatindicate the specialty for each doctor, so that the user can associatedmedical encounters with doctor approvals. The server configurationmodule 155 generates (550 b) a rule for the medical practice that when anew doctor is added to the medical practice management system 100 thenthe specialty of the doctor, if the doctor has a specialty, has to beentered into the system 100.

In some examples, the configuration information is utilized to generatea data structure for the medical practice. The data structure caninclude, for example, data fields, tables, and/or rows for the database.The data structure can be stored, for example, in the medical practiceinformation database 165. For example, if the medical office includes anoral surgeon who does in-patient surgeries (e.g., wisdom teeth removal),then data structures can be created to include the information neededfor in-patient surgeries in the medical office.

In other examples, the requests generated (520) for additionalinformation are based on one or more insurance rules that apply to thepayor servers that are associated with the medical office. The payorservers are associated with the medical office based on the informationinputted by the user 110 about the medical office. The one or moreinsurance rules can be stored, for example, in the payor informationdatabase 175 and can be accessed, for example, through the payor module170. The payor module 170 can update, for example, the insurance rulesbased on information received from the payor servers (not shown).

In some examples, the configuration information includes informationthat selects information for submission to a payor server (e.g.,doctor's medical degree information). The configuration information caninclude, for example, information that formats information forsubmission to a payor server (e.g., doctor's medical degree has to be inthe format M.D. or O.D.).

In other examples, the configuration tool can be utilized to updateinformation for a medical practice. The information about a medicalpractice may need to be updated based changes to the medical practice(e.g., addition of new medical office, new doctor, new insurance plan).The updated configuration information that is generated based on the newinformation can be merged, for example, into the existing configurationinformation (e.g., adding new data structure for the new medicaloffice). In some examples, the new configuration information replacesthe existing configuration information in the medical practiceinformation database 165.

FIG. 6 is an exemplary flowchart 600 depicting determining if additionalinformation is needed and determining if the information is correctutilizing the medical practice management system 100 of FIG. 1. Themedical practice module 120 receives (610) first information that iscommunicated by the user 110. The server configuration module 155generates (620) requests for additional information from the user 110.The medical practice module 120 receives (630) second information thatis communicated by the user 110 in response to the requests foradditional information.

The server configuration module 155 determines (640) whether additionalinformation is needed for the configuration of the medical practice. Thedetermination (640) of whether additional information is needed includesprocessing one or more rules associated with payor servers which areassociated with the medical practice based on the information submittedby the user 110. If additional information is needed, then the serverconfiguration module 155 generates (644) requests for additionalinformation. The user 110 receives the requests for additionalinformation and submits additional information in response to therequests. The medical practice module 120 receives (646) the additionalinformation. The server configuration module 155 then determines (640)again whether additional information is needed for the configuration ofthe medical practice.

If no additional information is needed, then the server configurationmodule 155 checks (650) all of the received information for errors(e.g., missing information, incorrect information). If there are errorsin the received information, then the server configuration module 155generates (654) requests for correct information. The user 110 receivesthe requests for additional information and submits updated informationto the server configuration module 155. The medical practice module 120receives (656) the correct information.

If there are no errors in the received information or the errors havebeen corrected, the server configuration module 155 generates (660)configuration information for the medical practice to utilize themedical practice management system 100.

In some examples, the errors include incorrect information, missinginformation, and/or any other issue with the information. Theconfiguration information can include, for example, medical claimprocessing information, user interface information, data structureinformation, rule information, and/or any other type of medical officeconfiguration information. The errors can be, for example, automaticallycorrected by the system 100 based on information associated with themedical practice and/or rules associated with the medical practice.

In some examples, the medical practice module (e.g., 125, 220 a, 220 b)can be any computing device, personal computer, Windows-based terminal,network computer, wireless device, information appliance, RISC Power PC,X-device, workstation, mini computer, main frame computer, personaldigital assistant, and/or other computing device that has awindows-based desktop. In other examples, the medical practice module(e.g., 125, 220 a, 200 b) can connect to a network and has sufficientpersistent storage for executing a small, display presentation program(e.g., Java applet, CGI enable web page). Windows-oriented platformssupported by the medical practice module (e.g., 125, 220 a, 220 b) caninclude, for example and without limitation, Windows 3.X, Windows 95,Windows 98, Windows NT 3.51, Windows NT 4.0, Windows 2000, Windows XP,Windows Vista, Windows CE, Windows Mobile, Mac/OS, OS X, Java, Unix,and/or Linux. The medical practice module can include, for example, avisual display device (e.g., a computer monitor), a data entry device(e.g., a keyboard), persistent or volatile storage (e.g., computermemory) for storing downloaded application programs, a processor, and/ora pointing device such as a mouse or digitized pen.

In other examples, the medical practice module includes a medicalpractice client user interface. The medical practice client interfacecan be, for example, text driven (e.g., DOS) and/or graphically driven(e.g., Windows). In some examples, the medical practice client userinterface is a web browser, such as Internet Explorer™ developed byMicrosoft Corporation (Redmond, Wash.), to connect to the medicalpractice management server. In other examples, the web browser uses theexisting Secure Socket Layer (SSL) support, developed by NetscapeCorporation, (Mountain View, Calif.) to establish the medical practicenetwork as a secure network.

In some examples, the medical practice management server and/or thepayor server can be any personal computer. In another example, themedical practice management server hosts one or more applications thatthe medical practice module can access (e.g., employee time entry,medical database). The medical practice management server can be, forexample, part and/or associated with a server farm (e.g., a logicalgroup of one or more servers that are administered as a single entity).

The above-described systems and methods can be implemented in digitalelectronic circuitry, in computer hardware, firmware, and/or software.The implementation can be as a computer program product (i.e., acomputer program tangibly embodied in an information carrier). Theimplementation can, for example, be in a machine-readable storage deviceand/or in a propagated signal, for execution by, or to control theoperation of, data processing apparatus. The implementation can, forexample, be a programmable processor, a computer, and/or multiplecomputers.

A computer program can be written in any form of programming language,including compiled and/or interpreted languages, and the computerprogram can be deployed in any form, including as a stand-alone programor as a subroutine, element, and/or other unit suitable for use in acomputing environment. A computer program can be deployed to be executedon one computer or on multiple computers at one site.

Method steps can be performed by one or more programmable processorsexecuting a computer program to perform functions of the invention byoperating on input data and generating output. Method steps can also beperformed by and an apparatus can be implemented as special purposelogic circuitry. The circuitry can, for example, be a FPGA (fieldprogrammable gate array) and/or an ASIC (application-specific integratedcircuit). Modules, subroutines, and software agents can refer toportions of the computer program, the processor, the special circuitry,software, and/or hardware that implements that functionality.

Processors suitable for the execution of a computer program include, byway of example, both general and special purpose microprocessors, andany one or more processors of any kind of digital computer. Generally, aprocessor receives instructions and data from a read-only memory or arandom access memory or both. The essential elements of a computer are aprocessor for executing instructions and one or more memory devices forstoring instructions and data. Generally, a computer can include, can beoperatively coupled to receive data from and/or transfer data to one ormore mass storage devices for storing data (e.g., magnetic,magneto-optical disks, or optical disks).

Data transmission and instructions can also occur over a communicationsnetwork. Information carriers suitable for embodying computer programinstructions and data include all forms of non-volatile memory,including by way of example semiconductor memory devices. Theinformation carriers can, for example, be EPROM, EEPROM, flash memorydevices, magnetic disks, internal hard disks, removable disks,magneto-optical disks, CD-ROM, and/or DVD-ROM disks. The processor andthe memory can be supplemented by, and/or incorporated in specialpurpose logic circuitry.

The components of the system can be interconnected by any form or mediumof digital data communication (e.g., a communication network). Examplesof communication networks include a LAN, WAN, the Internet, wirednetworks, and/or wireless networks.

The networks can be, for example, a wireless network and/or a wirednetwork. The networks can be, for example, a packet-based network and/ora circuit-based network. Packet-based networks can include, for example,the Internet, a carrier internet protocol (IP) network (e.g., LAN, WAN,campus area network (CAN), MAN, home area network (HAN)), a private IPnetwork, an IP private branch exchange (IPBX), a wireless network (e.g.,radio access network (RAN), 802.11 network, 802.16 network, generalpacket radio service (GPRS) network, HiperLAN), and/or otherpacket-based networks. Circuit-based networks can include, for example,the public switched telephone network (PSTN), a private branch exchange(PBX), a wireless network (e.g., RAN, bluetooth, code-division multipleaccess (CDMA) network, time division multiple access (TDMA) network,global system for mobile communications (GSM) network), and/or othercircuit-based networks.

The computing device can include, for example, a computer, a computerwith a browser device, a telephone, an IP phone, a mobile computingdevice (e.g., cellular phone, personal digital assistant (PDA) device,laptop computer, electronic mail device), and/or other communicationdevices. The browser device includes, for example, a computer (e.g.,desktop computer, laptop computer) with a world wide web browser (e.g.,Microsoft® Internet Explorer® available from Microsoft Corporation,Mozilla® Firefox available from Mozilla Corporation). The mobilecomputing device includes, for example, a personal digital assistant(PDA).

Doctor and physician are open ended and include any type of healthcareprofessional referred to as a doctor and/or a physician. Comprise,include, and/or plural forms of each are open ended and include thelisted parts and can include additional parts that are not listed.And/or is open ended and includes one or more of the listed parts andcombinations of the listed parts.

One skilled in the art will realize the invention may be embodied inother specific forms without departing from the spirit or essentialcharacteristics thereof. The foregoing embodiments are therefore to beconsidered in all respects illustrative rather than limiting of theinvention described herein. Scope of the invention is thus indicated bythe appended claims, rather than by the foregoing description, and allchanges that come within the meaning and range of equivalency of theclaims are therefore intended to be embraced therein.

1. A method for automated computerized configuration of a medicalpractice management system, the method comprising: receiving firstinformation associated with a medical practice; associating one or morepayor servers with the medical practice based on the first information;generating a request for second information based on (a) the firstinformation and (b) one or more insurance rules stored in an insurancerules database that apply to one or more payor servers, wherein the oneor more insurance rules apply to the one or more payor serversassociated with the medical practice; in response to the request,receiving second information which comprises information for submissionof medical claims to the one or more payor servers; generatingconfiguration information for the medical practice management systembased on the first information and the second information; andconfiguring the medical practice management system for one or more usersat the medical practice based on the configuration information.
 2. Themethod of claim 1 further comprising dynamically generating a userinterface for one or more users of the medical practice based on theconfiguration information, the user interface comprising one or morefields including information from the configuration information.
 3. Themethod of claim 1 further comprising updating stored configurationinformation for the medical practice stored in a medical practiceinformation database with the configuration information.
 4. The methodof claim 1 further comprising: determining whether to request additionalinformation based on the first information, the second information, andthe one or more insurance rules; generating a request for additionalinformation based on the first information, the second information, andthe one or more insurance rules; receiving additional information, whichcomprises information for submission of medical claims to the one ormore payor servers, based on the request for additional information; andgenerating configuration information for the medical practice managementsystem based on the first information, the second information, and theadditional information.
 5. The method of claim 1 wherein theconfiguration information comprises medical claim processinginformation, medical claim information utilized to generate medicalclaims for submission to one or more payor server, or both, the methodfurther comprising: generating one or more rules for the medicalpractice management system based on the configuration information; andstoring the one or more rules in the insurance rules database.
 6. Themethod of claim 1 further comprising: determining one or more errors areassociated with the first information, second information, or both basedon one or more rules associated with one or more payor servers;generating a request for correct information; and receiving correctinformation based on the request for correct information.
 7. The methodof claim 1 further comprising selecting third information for submissionto a payor server based on the configuration information.
 8. The methodof claim 7 further comprising formatting the third information forsubmission to the payor server based on the configuration information.9. A computer program product, tangibly embodied in an informationcarrier, the computer program product including instructions beingoperable to cause a data processing apparatus to: receive firstinformation associated with a medical practice; associate one or morepayor servers with the medical practice based on the first information;generate a request for second information based on (a) the firstinformation and (b) one or more insurance rules stored in an insurancerules database that apply to one or more payor servers, wherein the oneor more insurance rules apply to the one or more payor serversassociated with the medical practice; in response to the request,receive second information which comprises information for submission ofmedical claims to the one or more payor servers; generate configurationinformation for the medical practice management system based on thefirst information and the second information; and configure the medicalpractice management system for one or more users at the medical practicebased on the configuration information.
 10. A system for automatedcomputerized configuration of a medical practice management system, thesystem comprising: a medical practice module configured to: receivefirst information associated with a medical practice and receive secondinformation, which comprises information for submission of medicalclaims to one or more payor servers, based on a request; and configurethe medical practice management system for one or more users at themedical practice based on the configuration information; a serverconfiguration module in communication with the medical practice moduleconfigured to: associate one or more payor servers with the medicalpractice based on the first information; generate the request for thesecond information based on (a) the first information and (b) one ormore insurance rules that apply to the one or more payor servers,wherein the one or more insurance rules apply to the one or more payorservers associated with the medical practice; and generate configurationinformation for the medical practice management system based on thefirst information and the second information; and an insurance rulesdatabase in communication with the server configuration moduleconfigured to store the one or more insurance rules.